home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1087 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  8.3 KB
  1. Subject: Gem List
  2. Subject:  Re: digest
  3. Subject:  Shortcuts file and other digested material
  4. Subject:  GEM, etc.
  5. Date: Wed, 27 Jul 94 20:58 EST
  6. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  7. To: ems <gem-list@world.std.com>
  8. Subject: Gem List
  9. Message-Id: <71940728015817/0006795560PK1EM@mcimail.com>
  10. Precedence: bulk
  11.  
  12. Subject:  Re: digest
  13.  
  14. Michel:
  15. ------- 
  16. > Still, MasterBrowse _IS_ the fastest GEM text file viewer
  17. > available.
  18.  
  19. >From the versions I've seen, it's not only the fastest, but the buggiest!
  20.  
  21. Whoever:
  22. --------
  23. > Titeditor is faster than less actually.
  24.  
  25. 'Tit'editor? What is this, an editor with girlie pics in the dialogs?
  26.  
  27. > do much of anything.  I do not like the idea of having a desktop
  28. > for every application much, but I would like to be able to do it.
  29.  
  30. Actually, it's not unusual to see this on XWindows-based GUIs or on Windows
  31. for that matter.  Take a look at the major word processors on both
  32. platforms.  You'll see what the advantages are.  Especially in handling
  33. more than one open document at a time (or even iconified for that matter!)
  34.  
  35. -- Ken Hollis (Bitgate Software)
  36. -----
  37. Subject:  Shortcuts file and other digested material
  38.  
  39. Warwick:
  40. --------
  41. > Someone: (Ken Hollis)
  42. > >Whomever: (Still don't know)
  43.  
  44. > Actually, `Whomever' was quite close to the mark.  Using large rectangles
  45. > is the best approach.  (But the remainder of Whomever's solution was
  46. > incorrect, as Someone pointed out).
  47.  
  48. I don't think you understood what we were talking about.  I was simply
  49. trying to point out an effective way to handle background windows without
  50. having to use the right-and-left mouse button combination like TOS 2.06.
  51.  
  52. -- Ken Hollis (Bitgate Software)
  53. -----
  54. Subject:  GEM, etc.
  55.  
  56. Whomever (again; I think this is the same one I answered too...):
  57. ----------------------------------------------------------------- 
  58. > Well, after much thought, I have decided to abandon the German 
  59. > user-interface attitude of so overloading the interface with [sometimes 
  60. > marginally useful] features that the program becomes unusable.
  61.  
  62. Care to tell us *exactly* which 'marginally useful' features you mean?
  63.  
  64. > I see absolutely no point in going through all the trouble of adding 
  65. > countless features and options, 90% of which will not be used in any 
  66. > particular situation.  I want a window-library that makes my life easy 
  67. > with documentation that takes me less than a week to read and understand, 
  68. > well-commented, readable code, and simple bindings.
  69.  
  70. Care to elaborate on *exactly* which "90%" will not be used? I hope you're
  71. not talking about stuff like dialogs in windows, background button
  72. activation, and listboxes. Those are *essential* to a good windowing library.
  73. Abandon those and you abandon any point in writing a library at all.
  74.  
  75. In terms of complexity, you can write a fully working GEM program that
  76. lets you put dialogs in windows, move them around, close them, iconify
  77. them, click buttons in background, etc. with only about 10 lines of code
  78. (using XAES).
  79.  
  80. Simple bindings: #include <xaes.h>
  81.  
  82. Difficult, eh?
  83.  
  84. XAES's documentation includes lots of examples, something that lots of other
  85. libraries documentation fail to include. Maybe it's time they should start.
  86.  
  87. > I see no point in absolutely abandoning the GEM style.  It makes sense to 
  88. > make some modifications, yet some of the things you people are talking 
  89. > about like sending key-presses to a background window are not only hard 
  90. > to implement and counter-intuitive, but possibly DANGEROUS.  I will not 
  91. > send keypresses to a background window, and unless it's absolutely 
  92.  
  93. Nobody should *ever* send keypresses to anything but the window under
  94. current focus. It is *incredibly* confusing to do otherwise. Just flip
  95. this option on in some X11 window manager and you'll learn really damn
  96. quick to hate it (as well as auto-window topping.. this is a totally
  97. STUPID idea!)
  98.  
  99. By the way, I'm not sure what you mean by 'abandoning the GEM style'. There
  100. really is none! There is almost no consistency in GEM user interfaces,
  101. the way things work under different versions of TOS, etc.
  102.  
  103. I thought what we were trying to do here is establish *standards*, but if
  104. you're content on living with *no* standards, go right ahead.
  105.  
  106. > necessary, I don't see any point in sending mouse-clicks to a background 
  107. > window either.  It's just not GEM and it will only confuse and frustrate 
  108. > people.
  109.  
  110. Cop out. It's simple to do, a great convenience to the user as well. It
  111. will frustrate people more if they have to top every damn window just to
  112. use its gadgets, or if they have to induce hand cramps to drag a background
  113. window. If a user has more than 5 or 6 windows up, your interface will only
  114. get in the way and hamper the user, something a library should NEVER do.
  115.  
  116. > I see no point in screwing with GEM's top-window-had-focus method.  A 
  117. > tool bar in a background window doesn't, as far as I'm concerned, have 
  118. > focus when you click on it, so it's just fine with me.  I do not like 
  119. > giving focus to anything other than the top window.  The X-windows method 
  120. > is OK, but we're not using Xwindows... we're using GEM.  Don't forget that.
  121.  
  122. Fine, be content living in 1985. The rest of the world will leave you behind,
  123. along with MS-DOS 3.3.
  124.  
  125. > I want users to like my applications.  I want users to be able to use my 
  126. > applications.  Therefore, I will give the user only what he needs to be 
  127. > able to accomplish his task effectively.
  128.  
  129. Sounds like you really mean 'programmer' here rather than 'user'.
  130. And if your interface is so primitive that no user will ever want to use
  131. it, what's the point? Nobody will want to use a library that is going to
  132. be too restrictive on the programmer and user.
  133.  
  134. > With that, I have to ask what is in some of these other libraries that 
  135. > take up over 200k?  Loads and loads of more features.... most of which 
  136. > someone looking to get work done would never use.
  137.  
  138. And that only get linked in if you use them. Some people don't seem to
  139. understand that even if a library is 400k, applications aren't necessarily
  140. going to be large. Only if you use things will they get linked in. It just
  141. means that with that particular library, you have more options to choose
  142. from -- a larger 'toolbox' so to speak.
  143.  
  144. The test application for XAES that excercises the basic library functionality
  145. (dialogs in windows, iconifiable windows, background buttons, etc. etc.)
  146. only takes about 50k. That's for the full compiled application. That's not
  147. so big is it?
  148.  
  149. > My library will continue to grow, but I doubt it will grow to more than 
  150. > 50k, and I will always strive to make it simpler and simpler to use while 
  151. > it gets more and more powerful.
  152.  
  153. Kind of a contradiction here ;-) By limiting the size to 50k, you more or
  154. less limit what you can do with the library. At some point you will hit
  155. a brick wall.
  156.  
  157. > ]No, you just convert the WF_TOPPED message to button clicks.  You
  158. > ]can't do drags and such under normal TOS from a background window, unless
  159. > ]you use the right button.
  160. > Am I not getting my point across?  I want to do drags in background 
  161. > windows in normal TOS.  I KNOW how to convert WF_TOPPED messages into 
  162. > button clicks.  I'm already doing it!  I want to do drags too.
  163.  
  164. Ok, then use XAES. We allow you to drag/resize/scroll/close/etc windows in
  165. the background under normal TOS, even TOS 1.0.
  166.  
  167. > BTW, I'm using a Falcon 030.
  168.  
  169. You could be using a 68040, what has this got to do with the discussion?
  170.  
  171. > ]As to where to put it, no one has even agreed to the above.  They are
  172. > ]still arguing about ^A and trying to vote on it.  Damn stupid to vote
  173. > ]on ^A when you can configure it instead.
  174. > It's not stupid.  For one thing, I do not like the config file.  
  175.  
  176. Because it requires a little effort to implement?
  177.  
  178. > Secondly, if anyone uses Ctrl-A for select all, they're going to be in a 
  179. > mess without a lot of hacking.  It's just TOO EASY to hit Ctrl-A, and I 
  180. > don't want something as dangerous as Select-All assigned to it.  It's 
  181. > perfectly logical.
  182.  
  183. Instead of the programmer deciding what the user interface should be like,
  184. why not let the *USER* decide? (Gee, what a neat concept!) Duh!
  185.  
  186. > Something dangerously easy to hit like Ctrl-A should have something 
  187. > totally harmess assigned to it like Redraw-window.
  188.  
  189. Wow, ESC and RETURN are dangerously easy to hit, and their results could
  190. be even more devastating. Let's remove these keys altogether then.
  191.  
  192. Why not let the user assume responsibility for their own actions?
  193.  
  194. --Dan Hollis
  195.  
  196.